Sourced from junit's releases.

JUnit 4.13

Please refer to the release notes for details.

JUnit 4.13 RC 2

Please refer to the release notes for details.

JUnit 4.13 RC 1

Please refer to the release notes for details.

JUnit 4.13 Beta 3

Please refer to the release notes for details.

JUnit 4.13 Beta 2

Please refer to the release notes for details.

JUnit 4.13 Beta 1

Please refer to the release notes for details.

JUnit 4.12

Please refer to the release notes for details.

JUnit 4.12 Beta 3

Please refer to the release notes for details.

JUnit 4.12 Beta 2

No release notes provided.

JUnit 4.12 Beta 1

No release notes provided.

JUnit 4.11

No release notes provided.

Sourced from junit's changelog.

Summary of changes in version 4.13

Assertions

[Pull request #1054:](junit-team/junit#1054) Improved error message for assertArrayEquals when multi-dimensional arrays have different lengths

Previously, JUnit's assertion error message would indicate only that some array lengths x and y were unequal, without indicating whether this pertained to the outer array or some nested array. Now, in case of a length mismatch between two nested arrays, JUnit will tell at which indices they reside.

[Pull request #1154](junit-team/junit#1154) and #1504 Add assertThrows

The Assert class now includes methods that can assert that a given function call (specified, for instance, as a lambda expression or method reference) results in a particular type of exception being thrown. In addition it returns the exception that was thrown, so that further assertions can be made (e.g. to verify that the message and cause are correct).

[Pull request #1300:](junit-team/junit#1300) Show contents of actual array when array lengths differ

Previously, when comparing two arrays which differ in length, assertArrayEquals() would only report that they differ in length. Now, it does the usual array comparison even when arrays differ in length, producing a failure message which combines the difference in length and the first difference in content. Where the content is another array, it is described by its type and length.

[Pull request #1315:](junit-team/junit4#1315) assertArrayEquals shouldn't throw an NPE when test suites are compiled/run across versions of junit

A redundant field, fCause, was removed on v4.12, and was seemingly harmless because Throwable#initCause() could directly initialize cause in the constructor. Unfortunately, this backwards incompatible change got aggravated when a test class, compiled with the latest (4.12+), ran with an older version that depended on fCause when building the assertion message¹.

This change adds back fCause, and overrides getCause() to handle forward compatibility².

To ensure serializability of further changes in ArrayAssertionFailure (until excising these fields by a major rev), a unit test now runs against v4.11, v4.12 failures, asserting around #toString/getCause().

[1] [Issue #1178](junit-team/junit4#1178) details a particular case where gradle v2.2 is packaged with junit v4.11 and is used on running a test, generating test reports, despite specifying a particular version of junit (users would specify v4.12, or v4.+) in the test compile dependencies).

[2] Case if the test class is compiled with <= v4.11, where only fCause is initialized and not Throwable#cause, it can now fallback to the field, fCause, when building the message.

Test Runners

[Pull request #1037:](junit-team/junit#1037) BlockJUnit4ClassRunner#createTest now accepts FrameworkMethod

Subclasses of BlockJUnit4ClassRunner can now produce a custom test object based on the FrameworkMethod test being executed by implementing the new createTest(FrameworkMethod) method. The default implementation calls the existing createTest() method.

[Pull request #1082](junit-team/junit#1082): Ensure exceptions from BlockJUnit4ClassRunner.methodBlock() don't result in unrooted tests

The introduction of the runLeaf() method in BlockJUnit4ClassRunner in JUnit 4.9 introduced a regression with regard to exception handling. Specifically, in JUnit 4.9 through 4.12 the invocation of methodBlock() is no longer executed within a try-catch block as was the case in previous versions of JUnit. Custom modifications to methodBlock() or the methods it invokes may in fact throw exceptions, and such exceptions cause the current test execution to abort immediately. As a result, the failing test method is unrooted in test reports, and subsequent test methods are never invoked. Furthermore, any RunListener registered with JUnit is not notified.

As of JUnit 4.13, the invocation of methodBlock() is once again wrapped within a try-catch block. If an exception is not thrown, the resulting Statement is passed to runLeaf(). If an exception is thrown, it is wrapped in a Fail statement which is passed to runLeaf().

[Pull request #1286](junit-team/junit#1286): Provide better feedback to the user in case of invalid test classes

Only one exception per invalid test class is now thrown, rather than one per validation error. The message of the exception includes all of the validation errors.

Example:

org.junit.runners.InvalidTestClassError: Invalid test class 'com.example.MyTest':
  1. Method staticAfterMethod() should not be static
  2. Method staticBeforeMethod() should not be static

... (truncated)

• 038f751 [maven-release-plugin] prepare release r4.13
• 8fd0197 [maven-release-plugin] prepare for next development iteration
• c0bdd7d [maven-release-plugin] prepare release r4.13-rc-2
• ea2e229 [maven-release-plugin] prepare for next development iteration
• 0a5a2f8 [maven-release-plugin] prepare release r4.13-rc-2
• b51fa17 Ensure classes annotated with @OrderWith do not have @FixMethodOrder.
• 7c2f12c Never reorder classes annotated with @FixMethodOrder
• 6c5de81 Remove reference to obsolete mailing list
• 6c7cb4b Delete outdated docs
• fc3938a [maven-release-plugin] prepare for next development iteration
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)